إحداث ثورة في وحدات JavaScript: نظرة عميقة على استيرادات مرحلة المصدر

النظام البيئي لجافاسكريبت في حالة تطور مستمر. من بداياته المتواضعة كلغة برمجة نصية بسيطة للمتصفحات، نمت لتصبح قوة عالمية، تدفع كل شيء من تطبيقات الويب المعقدة إلى البنية التحتية من جانب الخادم. كان حجر الزاوية في هذا التطور هو توحيد نظام وحداتها، وحدات ES (ESM). ومع ذلك، حتى مع تحول ESM إلى المعيار العالمي، ظهرت تحديات جديدة، تدفع حدود ما هو ممكن. وقد أدى هذا إلى اقتراح جديد ومثير ومحتمل أن يكون تحويليًا من TC39: استيرادات مرحلة المصدر (Source Phase Imports).

يمثل هذا الاقتراح، الذي يتقدم حاليًا في مسار المعايير، تحولًا جوهريًا في كيفية تعامل JavaScript مع الاعتماديات. يقدم مفهوم "وقت البناء" أو "مرحلة المصدر" مباشرة إلى اللغة، مما يسمح للمطورين باستيراد وحدات يتم تنفيذها فقط أثناء التصريف، مما يؤثر على الكود النهائي وقت التشغيل دون أن يكون جزءًا منه أبدًا. يفتح هذا الباب لميزات قوية مثل الماكرو الأصلي، وتجريدات الأنواع بدون تكلفة، وتوليد الكود المبسط وقت البناء، كل ذلك ضمن إطار عمل موحد وآمن.

بالنسبة للمطورين في جميع أنحاء العالم، فإن فهم هذا الاقتراح هو المفتاح للتحضير للموجة التالية من الابتكار في أدوات JavaScript، وأطر العمل، وهندسة التطبيقات. سيستكشف هذا الدليل الشامل ماهية استيرادات مرحلة المصدر، والمشكلات التي تحلها، وحالات استخدامها العملية، والتأثير العميق الذي من المتوقع أن تحدثه على مجتمع JavaScript العالمي بأسره.

تاريخ موجز لوحدات JavaScript: الطريق إلى ESM

لتقدير أهمية استيرادات مرحلة المصدر، يجب علينا أولاً أن نفهم رحلة وحدات JavaScript. لفترة طويلة من تاريخها، افتقرت JavaScript إلى نظام وحدات أصلي، مما أدى إلى فترة من الحلول الإبداعية ولكنها مجزأة.

عصر المتغيرات العامة و IIFEs

في البداية، كان المطورون يديرون الاعتماديات عن طريق تحميل عدة وسوم <script> في ملف HTML. أدى هذا إلى تلويث مساحة الاسم العامة (الكائن window في المتصفحات)، مما أدى إلى تصادم المتغيرات، وترتيب تحميل غير متوقع، وكابوس في الصيانة. كان النمط الشائع للتخفيف من هذا هو تعبير الدالة المستدعى فورًا (IIFE)، الذي أنشأ نطاقًا خاصًا لمتغيرات النص البرمجي، مما يمنعها من التسرب إلى النطاق العام.

صعود المعايير التي يقودها المجتمع

مع نمو التطبيقات تعقيدًا، طور المجتمع حلولًا أكثر قوة:

• CommonJS (CJS): اشتهرت بفضل Node.js، تستخدم CJS دالة require() متزامنة وكائن exports. لقد صُممت للخادم، حيث تكون قراءة الوحدات من نظام الملفات عملية سريعة وحاجبة. طبيعتها المتزامنة جعلتها أقل ملاءمة للمتصفح، حيث تكون طلبات الشبكة غير متزامنة.
• تعريف الوحدة غير المتزامن (AMD): صُمم للمتصفح، حيث قام AMD (وأشهر تطبيقاته، RequireJS) بتحميل الوحدات بشكل غير متزامن. كانت صيغته أكثر تفصيلاً من CommonJS ولكنه حل مشكلة زمن استجابة الشبكة في تطبيقات العميل.

التوحيد القياسي: وحدات ES (ESM)

أخيرًا، قدم ECMAScript 2015 (ES6) نظام وحدات أصلي وموحد: وحدات ES. جلبت ESM أفضل ما في العالمين مع صيغة نظيفة وتصريحية (import و export) يمكن تحليلها بشكل ثابت. تسمح هذه الطبيعة الثابتة لأدوات مثل المُجمِّعات (bundlers) بإجراء تحسينات مثل التخلص من التعليمات البرمجية غير المستخدمة (tree-shaking) قبل تشغيل الكود. صُممت ESM لتكون غير متزامنة وهي الآن المعيار العالمي عبر المتصفحات و Node.js، مما يوحد النظام البيئي المجزأ.

القيود الخفية لوحدات ES الحديثة

تعتبر ESM نجاحًا هائلاً، لكن تصميمها يركز حصريًا على سلوك وقت التشغيل. تشير عبارة import إلى تبعية يجب جلبها وتحليلها وتنفيذها عند تشغيل التطبيق. هذا النموذج الذي يركز على وقت التشغيل، على الرغم من قوته، يخلق العديد من التحديات التي كان النظام البيئي يحلها بأدوات خارجية وغير قياسية.

المشكلة 1: انتشار اعتماديات وقت البناء

يعتمد تطوير الويب الحديث بشكل كبير على خطوة بناء. نستخدم أدوات مثل TypeScript و Babel و Vite و Webpack و PostCSS لتحويل كود المصدر الخاص بنا إلى تنسيق محسن للإنتاج. تتضمن هذه العملية العديد من الاعتماديات التي لا نحتاجها إلا في وقت البناء، وليس في وقت التشغيل.

لنأخذ TypeScript كمثال. عندما تكتب import { type User } from './types'، فأنت تستورد كيانًا ليس له مكافئ في وقت التشغيل. سيقوم مترجم TypeScript بمحو هذا الاستيراد ومعلومات النوع أثناء التصريف. ومع ذلك، من منظور نظام وحدات JavaScript، فهو مجرد استيراد آخر. يجب أن يكون لدى المُجمِّعات والمحركات منطق خاص للتعامل مع هذه الاستيرادات "الخاصة بالنوع فقط" والتخلص منها، وهو حل موجود خارج مواصفات لغة JavaScript.

المشكلة 2: السعي وراء التجريدات بدون تكلفة

التجريد بدون تكلفة هو ميزة توفر راحة عالية المستوى أثناء التطوير ولكنها تُصرَّف إلى كود عالي الكفاءة بدون أي عبء في وقت التشغيل. مثال مثالي هو مكتبة التحقق من الصحة. قد تكتب:

validate(userSchema, userData);

في وقت التشغيل، يتضمن هذا استدعاء دالة وتنفيذ منطق التحقق. ماذا لو كان بإمكان اللغة، في وقت البناء، تحليل المخطط وإنشاء كود تحقق محدد للغاية ومُدمَج، وإزالة استدعاء دالة `validate` العامة وكائن `userSchema` من الحزمة النهائية؟ هذا مستحيل حاليًا بطريقة موحدة. يجب شحن دالة `validate` بأكملها وكائن `userSchema` إلى العميل، حتى لو كان من الممكن إجراء التحقق أو تصريفه مسبقًا بشكل مختلف.

المشكلة 3: غياب الماكرو الموحد

الماكرو ميزة قوية في لغات مثل Rust و Lisp و Swift. إنها في الأساس كود يكتب كودًا في وقت التصريف. في JavaScript، نحاكي الماكرو باستخدام أدوات مثل إضافات Babel أو تحويلات SWC. المثال الأكثر انتشارًا هو JSX:

const element = <h1>Hello, World</h1>;

هذا ليس JavaScript صالحًا. تقوم أداة بناء بتحويله إلى:

const element = React.createElement('h1', null, 'Hello, World');

هذا التحويل قوي ولكنه يعتمد كليًا على أدوات خارجية. لا توجد طريقة أصلية داخل اللغة لتعريف دالة تقوم بهذا النوع من تحويل الصيغة. يؤدي هذا النقص في التوحيد إلى سلسلة أدوات معقدة وهشة في كثير من الأحيان.

تقديم استيرادات مرحلة المصدر: نقلة نوعية

تُعد استيرادات مرحلة المصدر إجابة مباشرة لهذه القيود. يقدم الاقتراح صيغة إعلان استيراد جديدة تفصل صراحة بين اعتماديات وقت البناء واعتماديات وقت التشغيل.

الصيغة الجديدة بسيطة وبديهية: import source.

import { MyType } from './types.js'; // استيراد قياسي لوقت التشغيل
import source { MyMacro } from './macros.js'; // استيراد جديد لمرحلة المصدر

المفهوم الأساسي: فصل المراحل

الفكرة الرئيسية هي إضفاء الطابع الرسمي على مرحلتين متميزتين لتقييم الكود:

1. مرحلة المصدر (وقت البناء): تحدث هذه المرحلة أولاً، ويتعامل معها "مضيف" JavaScript (مثل مُجمِّع، أو بيئة تشغيل مثل Node.js أو Deno، أو بيئة تطوير/بناء في المتصفح). خلال هذه المرحلة، يبحث المضيف عن إعلانات import source. ثم يقوم بتحميل وتنفيذ هذه الوحدات في بيئة خاصة ومعزولة. يمكن لهذه الوحدات فحص وتحويل الكود المصدري للوحدات التي تستوردها.
2. مرحلة وقت التشغيل (وقت التنفيذ): هذه هي المرحلة التي نألفها جميعًا. يقوم محرك JavaScript بتنفيذ الكود النهائي الذي قد يكون قد تم تحويله. جميع الوحدات المستوردة عبر import source والكود الذي استخدمها تختفي تمامًا؛ لا تترك أي أثر في الرسم البياني لوحدات وقت التشغيل.

فكر في الأمر كمعالج مسبق موحد وآمن ومدرك للوحدات مدمج مباشرة في مواصفات اللغة. إنه ليس مجرد استبدال نصي مثل معالج C المسبق؛ إنه نظام متكامل بعمق يمكنه العمل مع بنية JavaScript، مثل أشجار البنية المجردة (ASTs).

حالات الاستخدام الرئيسية والأمثلة العملية

تتضح القوة الحقيقية لاستيرادات مرحلة المصدر عندما ننظر إلى المشكلات التي يمكن أن تحلها بأناقة. دعنا نستكشف بعض حالات الاستخدام الأكثر تأثيرًا.

حالة الاستخدام 1: تعليقات أنواع أصلية وبدون تكلفة

أحد الدوافع الأساسية لهذا الاقتراح هو توفير موطن أصلي لأنظمة الأنواع مثل TypeScript و Flow داخل لغة JavaScript نفسها. حاليًا، `import type { ... }` هي ميزة خاصة بـ TypeScript. مع استيرادات مرحلة المصدر، يصبح هذا بناء لغويًا قياسيًا.

الحالي (TypeScript):

// types.ts
export interface User {
id: number;
name: string;
}

// app.ts
import type { User } from './types';
const user: User = { id: 1, name: 'Alice' };

المستقبل (JavaScript القياسي):

// types.js
export interface User { /* ... */ } // بافتراض اعتماد اقتراح صيغة الأنواع أيضًا

// app.js
import source { User } from './types.js';
const user: User = { id: 1, name: 'Alice' };

الفائدة: تخبر عبارة import source بوضوح أي أداة أو محرك JavaScript أن ./types.js هو تبعية لوقت البناء فقط. لن يحاول محرك وقت التشغيل أبدًا جلبها أو تحليلها. هذا يوحد مفهوم محو الأنواع، مما يجعله جزءًا رسميًا من اللغة ويبسط عمل المُجمِّعات، والمدققات، والأدوات الأخرى.

حالة الاستخدام 2: ماكرو قوي وصحي (Hygienic)

الماكرو هو التطبيق الأكثر تحويلاً لاستيرادات مرحلة المصدر. يسمح للمطورين بتوسيع صيغة JavaScript وإنشاء لغات قوية خاصة بالمجال (DSLs) بطريقة آمنة وموحدة.

دعنا نتخيل ماكرو تسجيل بسيط يقوم تلقائيًا بتضمين الملف ورقم السطر في وقت البناء.

تعريف الماكرو:

// macros.js
export function log(macroContext) {
// سيوفر 'macroContext' واجهات برمجة تطبيقات لفحص موقع الاستدعاء
const callSite = macroContext.getCallSiteInfo(); // على سبيل المثال، { file: 'app.js', line: 5 }
const messageArgument = macroContext.getArgument(0); // احصل على شجرة البنية المجردة للرسالة // إرجاع شجرة بنية مجردة جديدة لاستدعاء console.log
return `console.log("[${callSite.file}:${callSite.line}]", ${messageArgument})`;
}

استخدام الماكرو:

// app.js
import source { log } from './macros.js'; const value = 42;
log(`The value is: ${value}`);

كود وقت التشغيل المُصرَّف:

// app.js (بعد مرحلة المصدر)
const value = 42;
console.log("[app.js:5]", `The value is: ${value}`);

الفائدة: لقد أنشأنا دالة log أكثر تعبيرًا تقوم بإدخال معلومات وقت البناء مباشرة في كود وقت التشغيل. لا يوجد استدعاء لدالة log في وقت التشغيل، فقط console.log مباشر. هذا تجريد حقيقي بدون تكلفة. يمكن استخدام هذا المبدأ نفسه لتنفيذ JSX، و styled-components، ومكتبات التدويل (i18n)، وغير ذلك الكثير، كل ذلك بدون إضافات Babel مخصصة.

حالة الاستخدام 3: توليد الكود المتكامل وقت البناء

تعتمد العديد من التطبيقات على توليد الكود من مصادر أخرى، مثل مخطط GraphQL، أو تعريف Protocol Buffers، أو حتى ملف بيانات بسيط مثل YAML أو JSON.

تخيل أن لديك مخطط GraphQL وتريد إنشاء عميل محسن له. اليوم، يتطلب هذا أدوات سطر أوامر خارجية وإعداد بناء معقد. مع استيرادات مرحلة المصدر، يمكن أن يصبح جزءًا متكاملاً من الرسم البياني لوحداتك.

وحدة المولد:

// graphql-codegen.js
export function createClient(schemaText) {
// 1. تحليل schemaText
// 2. توليد كود JavaScript لعميل محدد الأنواع
// 3. إرجاع الكود المولد كسلسلة نصية
const generatedCode = `
export const client = {
query: { /* ... طرق مولدة ... */ }
};
`;
return generatedCode;
}

استخدام المولد:

// app.js
// 1. استيراد المخطط كنص باستخدام تأكيدات الاستيراد (ميزة منفصلة)
import schema from './api.graphql' with { type: 'text' }; // 2. استيراد مولد الكود باستخدام استيراد مرحلة المصدر
import source { createClient } from './graphql-codegen.js'; // 3. تنفيذ المولد في وقت البناء وإدخال مخرجاته
export const { client } = createClient(schema);

الفائدة: العملية برمتها تصريحية وجزء من الكود المصدري. لم يعد تشغيل مولد الكود الخارجي خطوة منفصلة ويدوية. إذا تغير `api.graphql`، فإن أداة البناء تعرف تلقائيًا أنها بحاجة إلى إعادة تشغيل مرحلة المصدر لـ `app.js`. هذا يجعل سير عمل التطوير أبسط وأكثر قوة وأقل عرضة للخطأ.

كيف تعمل: المضيف، والصندوق الرملي، والمراحل

من المهم أن نفهم أن محرك JavaScript نفسه (مثل V8 في Chrome و Node.js) لا ينفذ مرحلة المصدر. تقع المسؤولية على عاتق بيئة المضيف.

دور المضيف

المضيف هو البرنامج الذي يقوم بتصريف أو تشغيل كود JavaScript. يمكن أن يكون هذا:

• مُجمِّع مثل Vite أو Webpack أو Parcel.
• بيئة تشغيل مثل Node.js أو Deno.
• حتى المتصفح يمكن أن يعمل كمضيف للكود الذي يتم تنفيذه في أدوات المطورين الخاصة به أو أثناء عملية بناء خادم التطوير.

ينظم المضيف العملية ذات المرحلتين:

1. يقوم بتحليل الكود ويكتشف جميع إعلانات import source.
2. ينشئ بيئة معزولة ومحمية بصندوق رملي (تسمى غالبًا "Realm") خصيصًا لتنفيذ وحدات مرحلة المصدر.
3. ينفذ الكود من الوحدات المصدرية المستوردة داخل هذا الصندوق الرملي. تُمنح هذه الوحدات واجهات برمجة تطبيقات خاصة للتفاعل مع الكود الذي تقوم بتحويله (مثل واجهات برمجة تطبيقات معالجة شجرة البنية المجردة).
4. يتم تطبيق التحويلات، مما ينتج عنه كود وقت التشغيل النهائي.
5. يتم بعد ذلك تمرير هذا الكود النهائي إلى محرك JavaScript العادي لمرحلة وقت التشغيل.

الأمان والصندوق الرملي أمران حاسمان

تشغيل الكود في وقت البناء يطرح مخاطر أمنية محتملة. يمكن لبرنامج نصي خبيث وقت البناء أن يحاول الوصول إلى نظام الملفات أو الشبكة على جهاز المطور. يركز اقتراح استيراد مرحلة المصدر بشدة على الأمان.

يعمل كود مرحلة المصدر في صندوق رملي مقيد للغاية. بشكل افتراضي، ليس لديه وصول إلى:

• نظام الملفات المحلي.
• طلبات الشبكة.
• المتغيرات العامة لوقت التشغيل مثل window أو process.

يجب أن يتم منح أي إمكانيات مثل الوصول إلى الملفات بشكل صريح من قبل بيئة المضيف، مما يمنح المستخدم تحكمًا كاملاً فيما يُسمح لبرامج البناء النصية بفعله. هذا يجعله أكثر أمانًا بكثير من النظام البيئي الحالي للإضافات والبرامج النصية التي غالبًا ما يكون لها وصول كامل إلى النظام.

التأثير العالمي على النظام البيئي لجافاسكريبت

سيؤدي إدخال استيرادات مرحلة المصدر إلى إحداث موجات في جميع أنحاء النظام البيئي العالمي لجافاسكريبت، مما يغير بشكل أساسي كيفية بناء الأدوات وأطر العمل والتطبيقات.

لمؤلفي أطر العمل والمكتبات

يمكن لأطر العمل مثل React و Svelte و Vue و Solid الاستفادة من استيرادات مرحلة المصدر لجعل مصرفاتها جزءًا من اللغة نفسها. يمكن تنفيذ مصرف Svelte، الذي يحول مكونات Svelte إلى JavaScript خالص محسن، كـ ماكرو. يمكن أن يصبح JSX ماكرو قياسيًا، مما يلغي حاجة كل أداة إلى تنفيذها المخصص للتحويل.

يمكن لمكتبات CSS-in-JS إجراء كل تحليل الأنماط وتوليد القواعد الثابتة في وقت البناء، وشحن وقت تشغيل ضئيل أو حتى بدون وقت تشغيل، مما يؤدي إلى تحسينات كبيرة في الأداء.

لمطوري الأدوات

لمنشئي Vite و Webpack و esbuild وغيرهم، يقدم هذا الاقتراح نقطة امتداد قوية وموحدة. بدلاً من الاعتماد على واجهة برمجة تطبيقات إضافية معقدة تختلف بين الأدوات، يمكنهم الاتصال مباشرة بمرحلة وقت البناء الخاصة باللغة. قد يؤدي هذا إلى نظام بيئي أدوات أكثر توحيدًا وقابلية للتشغيل البيني، حيث يعمل الماكرو المكتوب لأداة واحدة بسلاسة في أداة أخرى.

لمطوري التطبيقات

بالنسبة لملايين المطورين الذين يكتبون تطبيقات JavaScript كل يوم، فإن الفوائد عديدة:

• تكوينات بناء أبسط: اعتماد أقل على سلاسل معقدة من الإضافات للمهام الشائعة مثل التعامل مع TypeScript أو JSX أو توليد الكود.
• أداء محسن: ستؤدي التجريدات الحقيقية بدون تكلفة إلى أحجام حزم أصغر وتنفيذ أسرع في وقت التشغيل.
• تجربة مطور محسنة: ستفتح القدرة على إنشاء امتدادات مخصصة خاصة بالمجال للغة مستويات جديدة من التعبيرية وتقليل الكود المتكرر.

الوضع الحالي والطريق إلى الأمام

استيرادات مرحلة المصدر هي اقتراح يتم تطويره بواسطة TC39، اللجنة التي توحد JavaScript. تتكون عملية TC39 من أربع مراحل رئيسية، من المرحلة 1 (اقتراح) إلى المرحلة 4 (منتهية وجاهزة للتضمين في اللغة).

اعتبارًا من أواخر عام 2023، وصل اقتراح "استيرادات مرحلة المصدر" (جنبًا إلى جنب مع نظيره، الماكرو) إلى المرحلة 2. هذا يعني أن اللجنة قد قبلت المسودة وتعمل بنشاط على المواصفات التفصيلية. تم تحديد الصيغة الأساسية والدلالات إلى حد كبير، وهذه هي المرحلة التي يتم فيها تشجيع التنفيذات والتجارب الأولية لتقديم الملاحظات.

هذا يعني أنه لا يمكنك استخدام import source في متصفحك أو مشروع Node.js اليوم. ومع ذلك، يمكننا أن نتوقع رؤية دعم تجريبي يظهر في أدوات البناء والمترجمات الحديثة في المستقبل القريب مع نضوج الاقتراح نحو المرحلة 3. أفضل طريقة للبقاء على اطلاع هي متابعة مقترحات TC39 الرسمية على GitHub.

الخاتمة: المستقبل هو وقت البناء

تمثل استيرادات مرحلة المصدر واحدة من أهم التحولات المعمارية في تاريخ JavaScript منذ إدخال وحدات ES. من خلال إنشاء فصل رسمي وموحد بين وقت البناء ووقت التشغيل، يعالج الاقتراح فجوة أساسية في اللغة. إنه يجلب القدرات التي طالما رغب فيها المطورون - الماكرو، والبرمجة الوصفية وقت التصريف، والتجريدات الحقيقية بدون تكلفة - من عالم الأدوات المخصصة والمجزأة إلى جوهر JavaScript نفسه.

هذا أكثر من مجرد قطعة جديدة من الصيغة؛ إنها طريقة جديدة للتفكير في كيفية بناء البرامج باستخدام JavaScript. إنها تمكن المطورين من نقل المزيد من المنطق من جهاز المستخدم إلى جهاز المطور، مما ينتج عنه تطبيقات ليست فقط أكثر قوة وتعبيرًا ولكنها أيضًا أسرع وأكثر كفاءة. مع استمرار الاقتراح في رحلته نحو التوحيد القياسي، يجب على مجتمع JavaScript العالمي بأسره أن يراقب بترقب. عصر جديد من الابتكار في وقت البناء يلوح في الأفق.